The 3GPP group has specified a protocol known as the GPRS Tunneling Protocol (GTP), which is intended to provide a mechanism for the mobility management of packet data traffic associated with mobile terminals. GTP is implemented between an IP anchor point and an IP access point within the GPRS core network. A primary role of the anchor point is the allocation of IP addresses to mobile user equipment (UE) terminals (from a fixed pool of addresses). An IP address is allocated to a UE for the duration of a session. The access point is responsible for registering the current location of a UE with an anchor node to allow the anchor node to tunnel packets to a UE having an IP address allocated to it.
A parallel mobility protocol known as Proxy Mobile IP (PMIP) has been specified by the 3GPP Internet Engineering Task Force, IETF (see draft-ieff-netImmproxymip6-06.txt) in order to allow GTP-like functionality to be introduced to other packet data networks, e.g. CDMA2000-based networks. PMIP refers to the anchor point as a “Local Mobility Anchor” (LMA) and to the access point as a “Mobility Access Gateway” (MAG).
PMIPv6 protocol enables legacy UEs to retain connectivity to the Internet and other nodes with the same IP address while moving between access networks [see “Proxy Mobile IPv6”, S. Gundavelli, IETF Request for Comments 5213]. The home operator's LMA assigns an IPv4 Home Address (HoA) or an IPv6 Home Network Prefix (HNP) for the UE and these addresses are transmitted to the UE via the MAG. As shown in FIG. 1, when at step 101 a UE 10 attaches to an access network, a MAG 12 in that access network registers with the LMA 14 of the UE by exchanging with the LMA 14 a Proxy Binding Update (PBU) message at step 102 and a Proxy Binding Acknowledgement (PBA) message at step 103. In these messages the MAG 12 learns the IPv4 HoA and the IPv6 HNP of the UE 10. Both the MAG 12 and the LMA 14 also set up routing for the HoA and HNP of the UE 10 so that the traffic flows from/to the UE 10 inside a bi-directional tunnel between the MAG 12 and the LMA 14.
After the UE 10 has attached to the access network and the MAG 12 has registered the UE 10 with the LMA 14, the UE 10 still needs to learn the IPv4 HoA and the IPv6 HNP. This is done with normal IP information configuration methods. The normal automated method is the use of the Dynamic Host Configuration Protocols, DHCPv4 [see “Dynamic Host Configuration Protocol”, R. Droms, IETF RFC2131] in IPv4, and in IPv6 either a stateless DHCPv6 method [see “IPv6 Stateless Address Autoconfiguration”, S. Thomas, IETF RFC2462], or a stateful DHCPv6 method [see “Dynamic Host Confguration Protocol for IPV6”, R. Droms, IETF RFC3315]. Thus, as shown in FIG. 1, at step 104 the MAG 12 informs the UE 10 that it has successfully attached to the access network, and the UE 10 initiates the DHCP procedure by sending (step 105) a DHCP discovery message. The MAG 12 acts a DHCP relay and simply relays all DHCP packets between the UE 10 and the DHCP server in the home network (normally in the LMA 14, as shown in FIG. 1). The exchange of messages includes a DHCP offer (106), a DHCP request (107) and a DHCP acknowledgement (108).
After registration the LMA 14 intercepts all downlink packets addressed to the UE 10 and tunnels them to the MAG 12, which, in turn, de-capsulates them and delivers them to the UE 10. Uplink packets of the UE 10 are encapsulated by the MAG 12, tunnelled to the LMA 14, where they are de-capsulated and routed further based on the destination address of the packet.
When the UE 10 needs to refresh its IPv4 or IPv6 address (for example due to a timeout) it sends a DHCP refresh request (109) which is relayed to the LMA 14 and receives back a DHCP acknowledgement (110)
When a UE moves and attaches to the access network via a new MAG, the new MAG sends an update of location to the LMA in the form of a PBU message. The LMA acknowledges the receipt of the message by sending a PBA and redirects the tunnel to the new MAG. Note that IP address assignment is performed only once.
When the DHCPv4 and/or DHCPv6 method are used, the PMIPv6 protocol requires the DHCP server to be situated at the LMA because this is where the protocol dictates that all the required DHCP information is sent to. This means that after normal PMIPv6 registration the MAG and LMA still need to pass DHCP messages between each other every time the UE sends and resends the DHCP messages to the MAG. This is a waste of network resources.
In addition, when the MAG and the LMA are part of different subnets (which is normally the case), the LMA cannot know the default gateway addresses of the MAG domain, and is thus configured to send its own default gateway addresses. Later on, if the connection from the UE to the MAG is not a tunnel (i.e. the default gateway of the UE is not setup in such a way that all traffic goes via a point-to-point connection), then the UE sets up the default gateway according to the information it has received via the DHCP signaling. Because the LMA sends default router addresses which are only valid inside the LMA's subnet, and not in the MAG's subnet, the UE will set up a default gateway address that does not work. This is because the Address Resolution Protocol (ARP) will fail for the default gateway address configured in the UE. This means that the UE will not be able send packets outside its working domain.
The IETF has published an Internet Draft entitled ‘IPv4 Support for Proxy Mobile IPv6’ (see: draft-ietf-netlmm-pmip6-ipv4-support-06.txt) in which it is proposed to co-locate either the DHCP server or a DHCP relay agent and the MAG. In the case of the DHCP server, this can help to reduce the amount of signalling required provided that the DHCP server has all the required and up-to-date DHCP configuration information. However, there will be many situations where the UE's home operator LMA is not one that is known to the DHCP server, or where the DHCP configuration information has changed and needs to be up-dated. In either of these situations the information at the DHCP server co-located with the MAG would need to be up-dated or re-configured. A further problem arises because all the DHCP servers that are co-located with MAGs in an IPv6 domain have to be configured with the same set of DHCP option values to ensure that a UE will receive the same configuration values over any access links to the domain. Thus updating this information becomes a major task. In the case of the DHCP relay agent being co-located with the MAG, the DHCP signalling will still need to travel to/from the LMA.
The present invention has been conceived with the foregoing in mind. Although the invention is described in relation to DHCP, it will be appreciated that the principles could be applied to other existing or yet to be defined protocols for providing configuration information to a mobile terminal in a telecommunication network.